test_runner: support custom message for expectFailure#61563
test_runner: support custom message for expectFailure#61563nodejs-github-bot merged 2 commits intonodejs:mainfrom
Conversation
|
Review requested:
|
@JakobJingleheimer In that case, I'd be happy to pivot this PR to implement the expectFailure validation logic (accepting a string/regex to match the error) instead of just a message. Does that sound good, or is there someone else already working on it?" |
|
@vassudanagunta you were part of the original discussion; did you happen to start an implementation? To my knowledge though, no-one has started. I had planned to pick it up next week, but if you would like to do, go ahead. If you do, I think it would probably be better to start a new PR than to pivot this one. So open a draft and I'll add it to the test-runner team's kanban board so it gets proper visibility. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #61563 +/- ##
==========================================
+ Coverage 88.84% 89.75% +0.91%
==========================================
Files 674 674
Lines 204957 205682 +725
Branches 39309 39438 +129
==========================================
+ Hits 182087 184607 +2520
+ Misses 15088 13316 -1772
+ Partials 7782 7759 -23
🚀 New features to boost your workflow:
|
|
@JakobJingleheimer nope, haven't started this, though I had long ago implemented it in I think it's important to get the requirements nailed. IMHO, #61570. |
|
As I said, let's put together a proposal in the nodejs/test_runner repo 🙂 |
This comment was marked as resolved.
This comment was marked as resolved.
|
reviewed before reading the discussion; imo a string should work as in this PR whether or not it also supports accepting a regex. |
|
It could do. My concern is supporting this without considering the intended regex feature accidentally precluding that intended feature, or inadvertently creating a breaking change, or creating heavily conflicting PRs (very frustrating for the implementators). I think we can likely get both; we can easily avoid those problems with a quick proposal so everyone is on the same page 🙂
Please start a proposal like the ones already in that repo 🙂 https://github.com/nodejs/test-runner/tree/main/proposals we can discuss it in that PR |
|
conflicts fair; as long as the "should expect failure" uses truthiness (does an empty string count as true or false, though?), i can't foresee any semantic collision. |
1af3584 to
13aedaa
Compare
|
I've opened a proposal PR in the test-runner repository as suggested by @JakobJingleheimer. |
061f049 to
346ec8f
Compare
vassudanagunta
left a comment
There was a problem hiding this comment.
I think this needs to be documented a little better for the user.
|
@Han5991 the proposal isn't finished / accepted yet (still hasn't been reviewed by the rest of the test-runner team), so I think it's premature to resume this (the proposal isn't a requirement, but I think it's a good idea and will reduce churn, needless re-reviews, etc—and indeed, there was just earlier today another adjustment to align terms). I do appreciate the enthusiasm 😁 It's added to the team's agenda, so it'll get raised at the next meeting. |
This comment was marked as resolved.
This comment was marked as resolved.
Actually all I am proposing is that the decision be made "eyes wide open", with implications in full view. While API design is something I care a lot about, I understand this API so it's no skin off my back whichever way it goes. |
This comment was marked as outdated.
This comment was marked as outdated.
Commit Queue failed- Loading data for nodejs/node/pull/61563 ✔ Done loading data for nodejs/node/pull/61563 ----------------------------------- PR info ------------------------------------ Title test_runner: support custom message for expectFailure (#61563) Author sangwook <rewq5991@gmail.com> (@Han5991) Branch Han5991:test-runner/support-getxfail-message -> nodejs:main Labels needs-ci, commit-queue-squash, test_runner Commits 2 - test_runner: expose expectFailure message - test_runner: fix empty object test assert logic Committers 1 - sangwook <rewq5991@gmail.com> PR-URL: https://github.com/nodejs/node/pull/61563 Fixes: https://github.com/nodejs/node/issues/61570 Reviewed-By: Jordan Harband <ljharb@gmail.com> Reviewed-By: Aviv Keller <me@aviv.sh> Reviewed-By: Jacob Smith <jacob@frende.me> ------------------------------ Generated metadata ------------------------------ PR-URL: https://github.com/nodejs/node/pull/61563 Fixes: https://github.com/nodejs/node/issues/61570 Reviewed-By: Jordan Harband <ljharb@gmail.com> Reviewed-By: Aviv Keller <me@aviv.sh> Reviewed-By: Jacob Smith <jacob@frende.me> -------------------------------------------------------------------------------- ℹ This PR was created on Wed, 28 Jan 2026 14:50:42 GMT ✔ Approvals: 3 ✔ - Jordan Harband (@ljharb): https://github.com/nodejs/node/pull/61563#pullrequestreview-3719402319 ✔ - Aviv Keller (@avivkeller): https://github.com/nodejs/node/pull/61563#pullrequestreview-3723610081 ✔ - Jacob Smith (@JakobJingleheimer): https://github.com/nodejs/node/pull/61563#pullrequestreview-3857218091 ✘ Last GitHub CI failed ℹ Last Full PR CI on 2026-02-26T09:15:39Z: https://ci.nodejs.org/job/node-test-pull-request/71464/ - Querying data for job/node-test-pull-request/71464/ ✔ Build data downloaded ✔ Last Jenkins CI successful -------------------------------------------------------------------------------- ✔ Aborted `git node land` session in /home/runner/work/node/node/.ncuhttps://github.com/nodejs/node/actions/runs/22437607383 |
|
It seems like github ci failed. Should I try running it again with rebase? |
|
CI didn't actually fail though. Earlier this morning I asked one of the CI maintainers; I'm waiting to hear back. |
|
Landed in 2e1265a |
Summary
This PR enhances the
expectFailureoption in the test runner to accept different types of values, enabling both custom failure labels and robust error validation. This implementation is referenced from and inspired by nodejs/test-runner#10.Changes
The
expectFailureoption now supports the following types:String: Treated as a failure label (reason).
RegExp / Function / Error Class: Treated as a matcher to validate the thrown error (similar to
assert.throws).Object:
labelormatchproperties, it's treated as a configuration object.Inheritance:
expectFailurefrom their parent suite. This allows marking an entire suite as expected to fail.References
expectFailurelabel and/or matcher test-runner#10Resolves: #61570